Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@app/profile/`[userId]/page.tsx:
- Around line 45-69: myClaims currently treats bountyResponse?.data as empty
which hides loading/error states; update the logic around the useMemo in
page.tsx to respect bountyResponse.isLoading and bountyResponse.error (or
equivalent) instead of silently returning an empty array: detect isLoading and
make the component render a spinner/placeholder for the "My Claims" tab, detect
error and render an error message, and only compute myClaims from
bountyResponse.data when not loading and no error; reference the useMemo hook
named myClaims, the bountyResponse object, and the UI path that renders the "My
Claims" tab to wire the loading/error states into the rendered output.
- Around line 53-59: The frontend branch that maps bounty.status +
claimExpiresAt to "in-review" is out of sync with backend semantics: remove the
heuristic in app/profile/[userId]/page.tsx that sets status = "in-review" (the
code inspecting bounty.status and bounty.claimExpiresAt) and instead rely on the
backend-normalized status (or a single canonical mapper that consumes
BountyLogic.processBountyStatus() output). Ask backend team whether expired
claims are auto-reverted to "open" or should map to a review UI state; then
either (a) accept only the backend statuses ('open'|'claimed'|'closed') and
derive UI labels from them, or (b) implement a documented mapping function
(e.g., mapBackendBountyStatusToUI) that explicitly translates backend statuses
to UI states and uses server-provided processed status rather than computing
"in-review" locally.
- Line 20: The component currently calls useBounties(), which only returns the
first page and omits claims on subsequent pages; replace useBounties() with
useInfiniteBounties(), then call flattenBountyPages() on the returned pages to
produce a single list before applying the claimedBy filter (e.g., where you
currently filter bountyResponse.data by claimedBy). Update any variable names as
needed (bountyResponse → infiniteBounties/pages) and ensure you handle
loading/hasNext/fetchNext logic from useInfiniteBounties() if required.

---

Nitpick comments:
In `@components/reputation/my-claims.tsx`:
- Around line 35-43: getClaimsBySection currently calls normalizeStatus
repeatedly for every section status inside the claims.filter loop, causing
O(sections × statuses × claims) work; to fix it, inside getClaimsBySection
precompute a Set of normalized statuses for each section (use CLAIM_SECTIONS and
normalizeStatus) once before filtering (e.g., const normalizedStatuses = new
Set(section.statuses.map(normalizeStatus))) and then change the inner filter to
check membership with normalizedStatuses.has(normalizedClaimStatus) so each
status is normalized only once per section.
- Around line 19-23: CLAIM_SECTIONS contains duplicate-equivalent status strings
because getClaimsBySection normalizes values; update CLAIM_SECTIONS so each
statuses array uses only the canonical, normalized forms (e.g., keep "in-review"
and remove "in review") to avoid redundant entries, reviewing all entries in
CLAIM_SECTIONS and ensuring they match the normalization logic used in
getClaimsBySection.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@app/api/compliance/terms/route.ts`:
- Around line 9-11: The catch block in the GET handler in
app/api/compliance/terms/route.ts currently swallows errors; update the catch to
log the caught error (include the Error object and a clear message) before
returning the 500 response so failures inside
TermsService.getCurrentTermsVersion() are recorded (match the pattern used in
compliance/status/route.ts, e.g., console.error("Failed to fetch terms:",
error)). Ensure you reference the same handler function where
TermsService.getCurrentTermsVersion() is called and keep the response behavior
unchanged.

In `@app/api/compliance/upgrade/route.ts`:
- Around line 39-41: The GET handler in app/api/compliance/upgrade/route.ts
currently uses a bare catch that swallows exceptions from
VerificationService.getVerificationStatus(); update the catch to accept the
error (e.g., "err") and log the error with the existing logger (or
console.error) before returning the 500 NextResponse so failures are visible;
reference the GET handler and VerificationService.getVerificationStatus() when
locating the change and ensure the logged message provides context (e.g.,
"Failed to fetch verification status") along with the error object.

In `@components/compliance/appeal-dialog.tsx`:
- Around line 33-35: The catch in the AppealDialog component that handles
AppealService.submitAppeal currently forwards error.message verbatim to alert();
instead sanitize and limit what is shown by: normalize the caught error in the
catch block for AppealService.submitAppeal, extract message only if it matches a
safe whitelist/regex or otherwise use a generic "Failed to submit appeal"
fallback, strip newlines/stack traces, and truncate to a short max length (e.g.,
150–200 chars) before calling alert; update the catch (error: unknown) handling
in AppealDialog to perform these checks and transformations so internal server
details are never shown.

In `@components/compliance/document-upload.tsx`:
- Around line 43-45: The catch block that narrows error as Error and passes
error.message to setError can surface unsafe server-originated text in the UI;
change the catch in the upload flow (the try/catch around the onUpload call that
calls setError) to avoid rendering raw error.message by mapping known, safe
error cases to user-friendly messages and otherwise using a stable fallback like
"Upload failed" (while logging the original error for debugging via
console.error or a logger); update the code paths that call setError (and any UI
that reads that state) to use only the sanitized message.

In `@components/wallet/withdrawal-section.tsx`:
- Around line 46-48: The current validationError expression short-circuits when
isAmountWithinBalance is false, so users get no message when amount > balance;
add a new balanceError (e.g. const balanceError = !isAmountWithinBalance ?
'Amount exceeds available balance' : null) and keep validationError based on
validationData as-is, then render balanceError wherever validationError is shown
and include it in any combined error/Alert used by the withdrawal UI
(referencing validationError, balanceError, isAmountWithinBalance,
validationData and canWithdraw to locate the logic and button state).
- Around line 40-44: The effect calling validateWithdrawal on every keystroke
causes race conditions and hides over-balance errors; debounce parsedAmount
(e.g., with a useDebounce hook or lodash debounce) and use the debounced value
in the effect and as the argument to validateWithdrawal (update the effect deps
to [debouncedAmount, isValidAmount, isAmountWithinBalance, validateWithdrawal])
so mutations fire only after the user pauses, and change the error rendering
logic (where isValidAmount and isAmountWithinBalance are checked) to also show a
specific error when isAmountWithinBalance is false so users see why the button
is disabled; key symbols: parsedAmount, validateWithdrawal (from
useValidateWithdrawal), isValidAmount, isAmountWithinBalance.

In `@lib/services/geo-restriction.ts`:
- Around line 59-64: detectProxy currently returns false silently which hides a
compliance gap; create a tracking issue in the repo for "implement proxy
detection for compliance (OFAC risk)" and update the detectProxy function to
reflect its unimplemented status by adding an explicit TODO comment and a clear
runtime signal (e.g., log a warning and either throw a NotImplemented/Runtime
error or return null/undefined) so callers in GeoRestrictionService
(detectProxy) must handle the unknown result; include brief notes in the TODO
referencing recommended providers (IPHub, ip-api.com proxy field, IP2Proxy) and
update any caller logic to treat a non-boolean result as "unknown / require
manual review".

---

Outside diff comments:
In `@components/compliance/limits-display.tsx`:
- Around line 89-93: The progress-bar width currently uses Math.min(100,
percent) which prevents overflow but allows negative percent values; update the
inline style in the component that renders the div with className "bg-primary
h-2 rounded-full transition-all" to clamp percent into the 0–100 range (e.g.,
replace Math.min(100, percent) with a clamp such as Math.max(0, Math.min(100,
percent)) or a small helper like clampPercent(percent)) so the rendered width
never becomes negative or exceeds 100.

---

Nitpick comments:
In `@app/api/withdrawal/submit/route.ts`:
- Around line 24-30: The catch block in the route handler in
app/api/withdrawal/submit/route.ts currently always returns 400; change it to
return 400 only for client/validation errors and 500 for unexpected server
failures: detect client errors by checking known signatures (e.g. error
instanceof Error && (error.name === 'ValidationError' || (error as any).status
=== 400 || (error as any).statusCode === 400)) or by using your app's
BadRequest/ValidationError class if available, and call NextResponse.json({
error: message }, { status: 400 }) for those cases, otherwise log the error and
return NextResponse.json({ error: message }, { status: 500 }) for server-side
failures.

In `@lib/services/appeal.ts`:
- Around line 39-43: getUserAppeals currently returns references to the objects
stored in MOCK_APPEALS (unlike submitAppeal and getAppeal which return defensive
shallow copies), so callers can mutate the in-memory store; update
getUserAppeals to map the filtered/sorted results to shallow copies (e.g.,
return items via {...a} or equivalent) before returning to maintain the same
defensive-copy pattern and protect MOCK_APPEALS from external mutation.

In `@lib/services/geo-restriction.ts`:
- Line 62: Replace the non-idiomatic "void ip;" statement by renaming the unused
parameter "ip" to "_ip" in the function/method in geo-restriction.ts (remove the
"void ip;" line); i.e., change the parameter declaration from ip to _ip so the
unused-parameter warning is suppressed idiomatically and no inline void
statement is needed.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@app/profile/`[userId]/page.tsx:
- Around line 59-72: The "In Review" section is unreachable because myClaims
(built in the useMemo in page.tsx) only maps backend statuses to "open",
"claimed", or "completed", which never normalizes to the "in-review" variants
expected by CLAIM_SECTIONS/normalizeStatus; update the mapping in the myClaims
creation (the mapping inside useMemo that uses
flattenBountyPages(infiniteBounties?.pages)) to emit an "in-review" status when
appropriate (for example map a backend review indicator or a specific bounty
field such as bounty.reviewStatus or a combination like bounty.status ===
"claimed" && bounty.isUnderReview to "in-review"), or alternatively remove the
"In Review" entry from CLAIM_SECTIONS in components/reputation/my-claims.tsx so
the UI and backend statuses align. Ensure you reference myClaims,
flattenBountyPages, infiniteBounties, CLAIM_SECTIONS, and normalizeStatus when
making the change.
- Around line 21-34: The current logic auto-pages through all bounties
client-side by calling useInfiniteBounties() with no filters and then filtering
claimedBy === userId, causing unbounded fetches; update the code to avoid
fetching every page: either (a) modify useInfiniteBounties()/the underlying
query to accept a claimedBy/userId parameter so server-side filtering returns
only the user's claimed bounties (update any BountyListParams and server handler
accordingly), or if server changes aren’t yet possible, implement a client-side
safety cap—stop auto-fetching after N pages or remove the automatic
fetchNextPage in useEffect and fetch only a single page or limited pages
(useInfiniteBounties, fetchNextPage, hasNextPage, isFetchingNextPage) to prevent
unbounded pagination and the full skeleton blocking the UI.

In `@components/wallet/withdrawal-section.tsx`:
- Around line 80-84: canWithdraw can become true before the new debounced amount
is validated; update the canWithdraw logic to require the debounce to be settled
and an explicit successful validation result (and no validation in-flight)
before enabling submit. Specifically, modify the canWithdraw predicate that
currently references isValidAmount, isAmountWithinBalance, validationError, and
complianceData to also require debounceSettled && validationData?.valid === true
&& !validationMutation?.isLoading (or the equivalent isValidating flag) so the
button stays disabled during the debounce window and while a validation request
is pending.

---

Duplicate comments:
In `@app/api/compliance/upgrade/route.ts`:
- Around line 30-42: The GET route's previous issues are resolved: the handler
uses a no-argument signature GET() and the catch now logs the error; approve and
merge as-is. No code changes required—keep the GET() function and the
console.error("Error fetching verification status:", error) in the catch block,
and proceed to merge the change.

In `@components/compliance/appeal-dialog.tsx`:
- Around line 33-34: The catch block after calling AppealService.submitAppeal
swallows errors and only shows an alert; update the catch in the submit handler
for AppealDialog to log the error for developer observability by calling
console.error with a clear context string (e.g., "AppealService.submitAppeal
failed") and the caught error object before showing the existing alert, ensuring
you reference the submit handler that calls AppealService.submitAppeal so the
log is colocated with the existing alert.

In `@components/wallet/withdrawal-section.tsx`:
- Line 17: The debounce fix using useDebounce on parsedAmount and wiring the
effect to the debounced-derived booleans (so walletInfo.balance changes are
picked up) looks correct and addresses the stale mutation/validationData race;
keep validateWithdrawal triggered from the effect using the debounced value (and
ensure any mutation handlers guard against overwriting validationData by
validating request identity if present). Also remove the duplicated
review/comment block that was repeated for lines 40-48 so the file has only one
approval comment.

In `@lib/services/geo-restriction.ts`:
- Around line 59-65: The detectProxy method currently uses a non-idiomatic "void
ip" to silence the unused parameter and silently returns false; change the
parameter name from ip to _ip (e.g., detectProxy(_ip: string)) to indicate it is
intentionally unused and remove the void statement, and add a runtime warning
(e.g., console.warn('[GeoRestriction] detectProxy: not implemented — defaulting
to false')) inside detectProxy so callers/operators see that proxy detection is
not yet implemented while preserving the Promise<boolean> return of false.

---

Nitpick comments:
In `@app/api/compliance/upgrade/route.ts`:
- Around line 20-26: The catch block currently returns error.message to the
client for failures from VerificationService.createVerificationRequest (and
downstream calls like ComplianceService.getUserCompliance /
ComplianceService.updateVerificationStatus), which can leak internal details;
change it to always respond with a fixed, user-safe message (e.g., "Failed to
create verification request") while keeping the full error logged server-side
(console.error or processLogger) for debugging, and only expose specific domain
errors if you have a safe explicit whitelist/type (e.g., a custom DomainError
type) — update the catch in route.ts around the POST handler to implement this
pattern for VerificationService.createVerificationRequest and downstream
failures.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@components/bounty/sponsor-review-dashboard.tsx`:
- Around line 38-56: The updater is mutating external variable prevItem inside
the setItems updater, which breaks rollback in React Strict Mode; instead,
capture the original item from the current items snapshot before calling
setItems (e.g., const prevItem = items.find(it => it.submissionId === id)), then
call setItems with a pure updater that only returns the new array (no side
effects). Use that captured prevItem for the catch rollback logic so rollback
restores the true previous ReviewSubmission, and reference the existing symbols
id, action, setItems, items, and ReviewSubmission to locate and update the code.

---

Nitpick comments:
In `@components/bounty/sponsor-review-dashboard.tsx`:
- Around line 27-34: The current useEffect in which setItems merges submissions
into local state (using currIdMap.get(sub.submissionId) ?? sub) always favors
the local item and thus can permanently ignore server-updated statuses; change
the merge so it prefers the incoming server-provided sub unless the local item
is actively loading — i.e., when mapping submissions, check
currIdMap.get(sub.submissionId) and only return the local item when its
submissionId is present in a loadingIds set/array, otherwise return the server
sub (and add loadingIds to the effect dependency array); update references to
useEffect, setItems, currIdMap, submissions, loadingIds, and ReviewSubmission
accordingly.

In `@hooks/Use-bounty-detail.ts`:
- Around line 1-3: The file name Use-bounty-detail.ts uses a capital U and
breaks the lowercase hook naming convention which can cause case-sensitive
filesystem failures; rename the file to use-bounty-detail.ts and update its
import in components/bounty-detail/bounty-detail-client.tsx to match the new
lowercase filename so that the exported hook (used via bountyKeys and
bountiesApi/Bounty in the file) is resolved consistently across platforms.

In `@lib/mock-bounty.ts`:
- Around line 44-79: Add two additional objects to the mockBounties array so My
Claims covers all panels: create one entry with id "3" (status: "in-review",
claimedBy: "user-1", claimedAt set to a recent ISO date) and one entry with id
"4" (status: "completed", claimedBy: "user-1", claimedAt and a completed/closed
or updatedAt ISO date). Keep other fields (type, projectId/projectName,
issueTitle, rewardAmount, difficulty, tags, githubIssueUrl, issueNumber, etc.)
consistent with existing entries so components rendering mockBounties can
display data for the "In Review" and "Completed" sections.